The developing of software applications is a very complex and time-consuming activity, especially in modern data processing systems. In order to facilitate this activity, several software engineering techniques have been proposed in the last years.
Particularly, a consolidated practice is of reusing existing software components (rather than creating them ex novo). The possibility of assembling reused components into more complex software applications reduces the developing time and cost; moreover, the reused components are generally largely tested, so that their exploitation results in software applications that are more robust, fault tolerant and reliable. Examples of reused components that have become very popular are object-oriented classes, graphical libraries, and tracing or logging tools.
A problem of the reused components is that they must be embedded into the software applications. Therefore, the same reused component must be copied in every software application. This increases the size of the software applications and involves the replication of any maintenance activity. In addition, the multiple copies of the reused component involve a waste of processing resources for their execution. In any case, the results that are obtained by the different copies of the reused component cannot be shared in any way among the software applications. Those problems are particularly acute when the reused component has a complex structure (for example, when it consists of a software application on its own).
An evolution of the above-described technique consists of providing components that can be shared among multiple software applications (or exploiters). In this way, a single copy of each sharable (or simply shared) component is used and maintained for multiple exploiters, with reduced resource consumption and the possibility of sharing the results obtained.
However, the management of the shared components is decidedly nontrivial. Particularly, no effective solution is available for the installation of the shared components. Indeed, whenever a specific shared component is needed by an exploiter it cannot be installed directly (since the same shared component might be already available). On the other hand, the use of the available shared component involves customizing the (new) exploiter to make it recognize this shared component.
A further problem arises whenever the version of the available shared component is not adequate. In this case, it is necessary to stop all the exploiters that are using the available shared component (in order to prevent the generation of incoherent results). Once the available shared component has been upgraded to the desired version, the exploiters must be restarted individually. In this case as well, the new exploiter must be customized to make it recognize this shared component.
All of the above requires a series of manual operations by an administrator of the system, which operations have a detrimental impact on the productivity and reliability of the process.